VI.FUME

17 FUME Designer

概述完FUME是什麼之後，先來理解一下要怎麼使用FUME Designer Playground吧，
https://try.fume.health/

FUME Designer的主頁面由三個主欄位構成，
最左邊是輸入資料JSON，
右上欄位為FUME Mapping，
右下欄位則是轉換後的FHIR JSON。

在開發的過程其實就是不斷的撰寫前兩項的欄位，這個輸入的欄位JSON的各項名稱可以自訂也可以跟負責界接資料的負責人溝通定名，

兩個欄位都寫好了，確定FHIR轉換完成就直接複製右下角拿走即可，使用操作就是這麼簡單，

在最右上方的5個欄位中，由左向右數來分別是儲存、重整、Documentation、Github與側欄，

大致上都很容易理解，這裡要特別說明側欄的部分，側欄拉開之後有6個可展開欄位，
分別是Mappings, Aliases, Resource Templates, Profile Templates, Data Type Templates與Functions

第一項Mappings可以看到所有在Playground儲存過的FUME Mapping，要注意的地方是這裡只會儲存Map，輸入若對方未跟著以註解儲存於此的話，
使用者只能靠Map的內容來回猜輸入JSON，

筆者大部分對於FUME FLASH的理解都是從閱讀上面的Map成品拼湊而成的，非常受用。

第二項Aliases指的是在FUME Mapping中可以使用的別名代數，FUME提供了一個很方便的功能，儲存一個預設別名來節省篇幅，特別是那些Terminology長而惱人的URI，

例如$loinc -> http://loinc.org， $sct -> http://snomed.info/sct 等

這裡可以事先先提一下，這些別名事實上也是FHIR Resource，FUME將這些別名以ConceptMap的方式儲存在FHIR Server上，
而這些FUME Mapping事實上是StructureMap，利用了這些FHIR Resource的特性所以讓FUME對FHIR Server的支援性非常好。
這也是筆者在核心上會先講到FHIR Server的緣故，FUME可以利用FHIR Server上的這些Resource來進行轉換或加速編譯與轉換的速度。

第三到第五項分別是各種形式的Template，使用者可以直接使用這些模板更改填入的欄位，加速實作的速度，
以筆者的角度來說並不推薦使用，原因是若FUME Mapping的開發變得複雜的時候，這些模板的編排反而會讓開發變得不方便。

最後一項則是Functions，上面提供了FUME可以使用的內建Function提供使用者使用，然而，這項所列的Function僅為一部分，
實際上請閱讀FUME Documentation與JSONata Documentation，可以了解最詳細的使用方法。

要在這裡提醒一點是，雖然FUME Designer Playground很方便，操作界面很直觀簡潔，但公開網域畢竟是公共區域，
請不要將你認為有涉及機密或敏感性的資料在這上面輸入或使用，因為任何人都看得到，

此外，筆者在測試FUME與學習的時候曾經非常多次把這個工具玩到壞掉，FUME的FHIR輸出欄位與FHIR Server停止響應直到其自動重啟，
原因是因為實作的內容過大與頻繁的更動修改，造成對方Server超出回應負荷，盡量不要像筆者一樣把它玩壞了，我很抱歉。

在正式開始講FUME FLASH要怎麼寫之前，我們要先來談FUME Community(Engine)要怎麼樣安裝、設定與使用。
實用上因為免費版並沒有提供FUME Designer使用，使用者可以先在FUME Designer Playground試寫FUME Mapping，
在地端布設好FUME Engine後，可以透過REST的方式與FUME溝通並得到對應的FHIR文件，所以儘管FUME Designer被我們弄壞了還是可以進行開發與測試
只是開發的速度會降低不少。

今天的主題比較少一點，我本來還在想能不能多寫一點東西的，但資訊密度太高好像也很累，

明天開始來講地端的FUME Engine要怎麼安裝，這裡我會將docker-compose重新組成HAPI FHIR與FUME Community一起放在同個容器的模式啟動